第十一章 案例与经验

11.1问答搭建项目案例

在场景简单，一个人操作的情况下，在知识库开始搭建初期明确一条主线，知道知识点分类的逻辑就可以基本的明确知识库应该如何搭建了。

但是往往当公司的业务线变宽，产品线变长，流程变复杂，语料（语料，通常指历史的聊天记录，工单等也可）变多，时间紧急的情况下，一个人是难以搭建整个知识库的。

工作注意事项

搭建知识库时建议工作人员共同搭建，坐在一起便于沟通。

经验上来说，面对面半分钟能解决的事情，往往远程沟通要3-5分钟，甚至面对面传达的准确率也会更高，最好是两个人共同搭建，方便厘清知识库内容。

在搭建时要注意按照分类分工明确，可以按照分类逻辑将各部分分工下人员职责明确清楚。大于3个人时，需要有人负责进行检查和指导，掌控知识库搭建质量和进度。

后期针对知识点级别的变化（增加，合并，删除知识点，移动修改分类等），也要同步给所有共同参与人员，以便让其及时了解变化，避免不必要的沟通成本。

搭建过程中要明确搭建所处的阶段，及时切换搭建策略，挖掘，测试优化相互配合。

来看一个消费信贷场景的实操案例：

在项目前期我们可以适当整理项目甘特图，辅之以双方职责说明，提前说明双方需要做的工作。

这样，我们与客户就知道双方应该具有哪些实施资源，需要配置什么人力，上面这个知识库是按照1个人需要做20人天来规划的。

经验来看，使用SaaS有历史语料搭建知识库，全流程中可以做到一个人平均一天挖掘20个知识点，项目前期和后期挖掘的数量会少一些，集中搭建的时期，挖掘的会多一些。

私有部署项目因为沟通，远程，或者其他影响因素要在这个基础上慢大约1/3，平均一个人一天能完成15个知识点。

政策类项目，因为缺少相关的语料以及其他影响因素，所以预计的知识点以及答案往往和用户实际提问有较大偏差，在后期需要反复沟通修改的也相对较多，平均大约一个人一天做10个知识点。

前期准备，语料准备和清洗

在工作正式开始前，我们要做有些准备工作，将用户前期的聊天记录整理成可以导入系统的格式。

项目开始前，我们收到了用户的4个G对话数据，因为数据量大，所以确认需要通过数据库等技术来解决基本的清洗问题。

清洗的目的是保留有效的用户提问。

一般来说，语料数量比较大的情况下我们就保留用户有效的第一句话就可以了。来也也有相应的语料清洗工具可以使用， 数据量如果在30万行以下，使用Excel来处理也非常方便。

注意清洗之后，挖掘之前保留测试集。

1.搭建培训

因为客户或者外包人员对于一个系统的知识库搭建知识不是很了解，我们必须先进行培训，以便于让搭建人员了解机器人的工作逻辑，划分知识点的方法。

知识库层面的搭建培训所有的参与知识点挖掘的同学都要参加。

2.分类快速确认

在培训结束之后，我们邀请业务方领导对整个知识库的分类结构做了梳理。

知识库分类确认工作大致需要1.5-2个小时，也可以提前进行沟通，培训结束后花再半个小时确认一下。

分类基本上是按照口诀“一条主线，其他靠边；出现重复，早做功夫”来划分和定义的。

首先我们确定的最核心的主线是用户生命周期。用户生命周期中，从用户过来的第一个意图起，直到用户的最后离开意图就是整个生命周期主线了。

该客户的主要业务是发放贷款，那么用户过来的主线分类就是资料填写，审核，贷款的申请，而后是还贷，最后是用户注销。

为了这个主线业务，客户还有很多其他业务来支撑这个业务，比如说APP，微信号，支付宝，小程序等渠道应用，从而又产生了其他靠边分支，这里面的知识点有，比如，如何在微信绑定，APP注册，APP操作如修改手机号等等。

“出现重复，早做功夫”的意思是，有时一个分类或知识点会出现在主线的各个部分，如果没有明显的逻辑应该放在某一分类下面，这时我们将其放在最早出现的地方。

通常建议一个分类下有5-20个知识点，如果超出可以拆分子分类，少于5个可以看情况适当合并。

为什么要一个好分类

知识点的分类就像机器人的骨架，骨架确定好了之后，我们才能确认我们的知识点应该放在哪里，一个混乱的分类会导致业务人员自身都不了解知识点应该归属的分类，机器人当然也就搭建不好了。

只有清晰明了的分类，我们才能在搭建知识库的时候，搞清楚到底相似问和知识点应该如何归置。

3.挖掘搭建

挖掘：即从杂乱无章语料中提取出意图相同的相似问题的集合。

（ ↑ 就是说从聊天记录中将意思一样的用户提问聚成一堆）

分类确认之后，我们采用了按照分类的主线逐步给参加挖掘的业务人员分配任务.

注意第一次划分任务没有必要将所有分类全部划分下去，根据工作进度的快慢，我们可以将工作内容分为若干部分，逐步分配。

当对应分类工作完成后，可以对该分类的工作进行验收，主要验收事项有以下几点：

• 问该分类下的主要问题，看看能否正常回答；

• 进入关键词挖掘，查看对应分类是否被挖掘干净（一次挖掘，不补充新的挖掘语料时）；

• 检查必要的专有词汇和其同义词是否添加；

• 检查相似问是否干净，是否囊括了其他分类下的知识等（可先用知识库优化功能）；

当所有工作完成之后，我们需要对虽然挖掘出来但是相似问数量不够的知识点进行必须要的相似问补充，一般来说补充到10-30个就行。

挖掘搭建过程中使用到的功能主要有以下四个功能：

1. 语料管理 主要是将前期清洗后的语料放置到语料库中。

2. 句子挖掘 使用句子挖掘对上传的语料做聚类。按分类挖掘时主要使用关键词挖掘（根据关键词汇聚类）功能；若单人全量挖掘，一般使用机器挖掘（根据语句之间的相似程度自动聚类）功能。

3. 知识点配置高级功能-挖掘 基于该知识点已有相似问计算重要的关键词，按关键词在待挖掘库的语料中发现可能相关的问题，经挑选后添加至该知识点作为相似问题。

4. 相似说法学习 相似说法学习功能：为了查漏补缺可以使用已有的知识点对用户提问（语料）做自动判别形成待审核，方便添加。 PS：相似说法学习功能在运营期也非常有用。

通常的应用策略是：语料上传后，搭建前期主要使用挖掘功能，中期使用知识点配置中挖掘补充相似问题，后期使用相似说法学习查漏补缺。

Tips

在搭建初步完成后、上线前以及刚上线时期，我们可以运行知识库健康度测评看分数是否在90分上来检查有没有相似问错放，或者知识点归类有问题。

推荐在上线前、知识库做大量改动后、知识库运行半年后这样的时间点定期回顾知识库内所有相似问和知识点的对应关系是否正确。

回顾是指展开每个知识点的相似问，人工复查是否有放错或不符合要求的。

4.真实语料检查

我们前期预留的测试集语料现在就派上用场了，从里面抽取200-500条，进行模型测评，标注正确率（可以使用在线标注功能，注意无语义选择忽略或删除）。

通常来说，客户自己第一次搭建的过程中经常会犯一些小问题，造成初始准召偏低，准确率一般在70-80%之间，成熟训练师搭建出来一般是在80-90%之间。

然后我们根据测评结果进行优化，注意总结主要问题，在进行一到两轮优化之后，能达到90%以上的水平。

优化可以采用补充语料导入相似说法学习形成待审核进行补充等功能。

Tips

在知识库进行测评的同时，答案也要请业务同学进行检查，发现并修改答案中的问题，回复的相关注意事项可以参考添加机器人回复编写经验。

5.上线与优化

在达到上线标准之后，我们就可以开始对接（注意转人工逻辑，欢迎语，关联问题，机器人不知道时的兜底回复），对接之后需要做必要的测试（SAT，UAT测试）；测试达标之后，我们就可以考虑上线了。

一些大型集成项目我们也会在搭建的同时做开发对接工作，并提前约定好回复的形式及其他项目注意事项。

在上线后的前一周我们要注意用户的提问，每天挑选200条数据，进行标注和优化，尤其注意高频的提问以及错误。

此案例中，我们将知识库上线到对应渠道上之后，结果很快发现某一个特定渠道用户的常见提问没有覆盖到，在前几天的召回中出现了一部分错误。及时调整后，这个问题就解决了。

只有在机器人发现问题后及时予以调整我们才能给予用户更好的体验。

11.2无语料搭建经验

前期我们讲述的很多项目和案例都是在有历史聊天记录（有语料）的场景中搭建知识库。可往往在历史没有应用过客服系统的项目中，缺少相关语料，这种项目（无语料项目）该怎么搭建呢？

本篇将重点介绍无语料知识库搭建项目的方法。

1.明确应用场景

在项目开始前，要明确项目的定位、性质、应用渠道，预计每天来访客户数量，提问数量。构建用户画像，找到用户的关注点，这一步也可以咨询用户现有的服务人员或市场人员。

在项目开展前，大家的预期要明确，应用机器人并不能直接带来流量，更多的是，服务好现有用户，提高现有用户的转化，形成良好的口碑。

2.拆分形成知识点

如果项目没有明确的知识点，那需要拿到客户回答问题的列表，这个可以作为搭建的基本知识点。如客户没有问题列表，可以请客户总结常见的一些问题和答案。也有很多时候，客户会直接给一个政策通知、办理手册等搭建知识库，这时候就需要人工去拆解知识库。

相应地，非业务人员拆解知识库、从文本中拆分知识点，容易出现业务要点把握不准，不知道客户提问重点的问题。所以要在拆解完成之后和业务员人员核对。经验上来说，拆解知识点的时间花费是50个知识点/人天，如有特殊情况会有变动。

3.泛化相似问题

有语料项目，我们通过聚类挖掘等方法从聊天记录中发现用户的提问，形成机器人知识库中对应知识点的相似问题也就是机器人的学习资料。

若搭建知识库没有语料，我们则需要根据现有情况或资料先挑出来用户问的问题，然后通过人工撰写、爬虫爬取问题等方法来增加相似问题。

人工撰写就是模拟真实用户的提问来添加相似问（吾来上添加一条后，敲击“Enter”即可新增下一条）。

经验上来说，增加相似问题预计用时为200条/人天，如有特殊情况会有变动。

来也科技在长期实践过程中，也积累了许多收集相似问题的方法。

比如来也泛化平台，来也科技研发的相似问题通用收集内部工具。

其作用是输入一句或一批句子，通过不同来源泛化，输出跟目标句子含义相近的其他句子。

来源包括：

• 同义词替换：使用同义词词表进行词语替换

• 爬虫：根据输入的标准问题爬取多个知识类网站，过滤后给出相似问排序

• 全网搜索：以给定的网址为对象搜索所需要的数据，默认包含常见问答网站

• 长话短说：将长句子缩短为短句子

测试机器人的测试集也可以通过这些方法收集。

有语料和无语料项目的分析

从有语料（有聊天记录）和无语料（无聊天记录）项目的背景来说，我们可以做出这样的总结：

区别	有语料项目	无语料项目
应用场景	成熟，长期对话服务	不成熟，新设对话服务
用户量	一般有稳定流量	未上线，未知
知识点	有常见知识点	通常有文档等，无聊天记录
语料	有聊天记录	未上线，未知

11.3机器人回复编写经验

搭建机器人从来都是个系统工程，所以面向客户的展示也就是知识点的答案，是影响用户体验的非常重要的因素，并不是机器人回答对了知识点就结束了。

有的时候用户认为机器人没能解决问题，不一定是因为机器人没有召回正确的知识点，而是该知识点的答案没能解决用户的问题。

经过我们的长期实践发现，对于历史项目覆盖率，准确率，召回率较高（皆为90%以上）的机器人，至少40%的转人工是因为答案不能解决用户的问题。

下面将重点介绍五个保障用户问答基本体验的原则：

1.准确

指准确解答用户的问题，没有错别字，不说错话；说话不含糊、无歧义是指避免笼统模糊，引发其他问题或误解，这是对答案最根本的要求。

2.简洁适用

能应答当前情况，不啰嗦，简单明了，信息量适当，太长用户是不喜欢的。

过长的答案，在回复的时候就需要适当提炼要点，改进展示形式。

3.显性回答

要讲明白自己当前回答的是什么问题，简单来说，是指带问题回复，给用户回应，让用户知道机器人识别到了他的问题。

X 错误示例

Q:产检假请假流程中需要上传什么内容？

A:上传XXX附件，具体可咨询部门人事专员等相关人员。

答案没表明是针对产检假请假的答案。

在真实场景中我们发现这个问题往往是因为用户重复了这个问题好几次，机器人反复的回答他这个答案。

对于机器人训练师来说，这个答案对应产检假上传附件的知识点，但用户是不知道的。

〇 正确示例

Q:产检假请假流程中需要上传什么内容？

A:产检假请假流程中需要上传XXX附件，具体可咨询部门人事专员等相关人员。

这个答案就很直白的体现了知识点的标题，让用户能知道这个回复确实是正确的。

也有些机器人在配置时选择了知识点标题和回复一起发送的方式，但这显然不符合下面的这个自然友好原则。

4.自然友好

自然即和客服回复方式一致，像人，不要太机械，生硬，可适当措辞多样化。

友好是说有温度，关心用户的感受，一定不能辱骂侮辱胁迫用户，这个要求往低了说只要通顺即可，但是好的答案能让客户感觉如沐春风，心情愉悦。

5.无答案引导

这指的是在没有答案或者兜底时给用户指导获取信息的途径。

因为对于用户来说，我们提供的服务可能是完全陌生的，用户不会知道我们的服务范围或能力，这就需要我们告诉用户可操作范围或步骤。

〇 服务范围引导示例

Q:你好

A:你好呀，我是机器人小吾，我可以回答关于五险一金，个税扣缴相关的问题~您可以尝试问我“社保缴纳记录在哪里查询”。

这个引导我们也可以应用在用户打开后欢迎语等环节。（吾来支持的渠道可以在“对话搭建-个性化体验-用户事件-进入事件”进行配置后体验到。）

〇 兜底回复引导示例

Q:*……%￥#@￥%…

A:抱歉，您问的问题我还不知道呢，要不您换种问法问问我吧~~

您也可以点击窗口右下角的“转人工”按钮来获得人工客服的帮助。

必要的时候可以指引用户操作（一般用任务对话实现）或给出跳转链接，需要注意的是这个操作在关键词对话搭建也很常见。

〇 关键词回复引导示例

Q:社保

A:请问您想问关于社保的什么问题呢？

测试体验

试运行可以这样测试答案，让用户按照给定的知识库范围进行提问，自己使用即时沟通的机器人辅助人工进行回复的方式尝试回答。

Tips: 即时沟通即吾来自带的轻量客服系统，在自有渠道上可以接入用户提问，模拟客服进行回复，在回复时，输入上方会自动弹出机器人推荐的答案。

当你想要调整答案进行回复的时候，就说明原本的答案和处理方式可能是不够合适的。

机器人表现的智慧都是人类教与机器人的，在答案编写的角度上表现的尤其明显，优化机器人的诀窍就是像人像人再像人。

答案编写注意事项

使用标准普通话，容易理解，避免明显方言或个人习惯用语

避免错别字，网络用语，生僻词汇 e.g. 退火（货）有效期

语法完整，简明扼要，不要仅有词语，避免复杂的长句

不需要无用特殊符号，问候语，语气词等

长答案整理范式

标准问的描述部分+是什么答案（简洁版除了标题不超过10个字）。

遇到的情况1有以下解决办法：

解决方案1；可以进入XX-XX页面（点击链接直达），进行XX操作。

解决方案2；

遇到的情况2有以下解决办法：

解决方案1；

……

如果坚持要XXX，可以XXX（极端情况再补充）

如果还不能解决，考虑是XXX。附件截图示例如下：

图片1.

与答案相关的关联推荐知识点。

11.4任务规划简述

简要来说，我们需要同客户确认以下几个方面，明确一下对接期间双方的工作：

首先，大部分客户并不了解任务如何区分细节，这需要我们和客户一起来梳理任务和任务之间需要分为哪些环节，每个小环节的任务分别要完成什么事情，这些环节的优先级是什么样子的，一个用户进行任务的时候，到什么时候算是完成呢？

第二点是整理任务要素，这个要梳理我们需要从用户那里获取什么信息？用户的浏览路径是否会影响用户的问答表现和我们提供的服务？

关于用户需要提供的这些信息我们是否提前做过归纳总结，后期可以直接用作实体，专有词汇等等，是不是已经有现成的流程制度，甚至是流程图。

第三点和第四点分别是梳理对话案例和提炼任务流程。

对话案例我们要体现典型的任务场景，用户能做什么？服务开始和结束我们要注意哪些事情，这个闭环如何完成，以及一些重点的任务功能效果示意。

提炼任务流程我们需要梳理场景，意图，词槽和实体，定义流程规则，掌握任务的限制，约定好意图梳理的异常处理方法，以下是一些简单的示意：

对话示例编写

询问逻辑设计

实体的定义和整理

如果各个环节的关系比较复杂，我们就需要用流程图来表示整体的逻辑关系。下图是一个查询订单场景的示意：

如果需要展示清楚跨系统配合的逻辑就需要更进一步，使用泳道图来展示相关的图片。泳道图的特点就是分工明确，对象清晰，适合多业务协作。

任务对话的常见处理

下面这些都是来也科技在项目实践中做过的逻辑。

1. 前序回答是否会影响后续任务

确认逻辑，在很多信息收集类项目中，我们需要对用户的选择和输入做确认，根据确认的结果，可能有通过、不通过、修改填写内容等选择；跳题逻辑，前序回答造成后序题目无需回答或者根据不同的情况需要收集不同的信息。

1. 特殊情况如手机号缺位怎么办

是否需要输入位数错误等特殊提示，在一些做的比较细致的项目中，甚至会对手机号的各种情况做提示，比如国外手机号，手机号位数是否正确等。

1. 收集逻辑是什么

在收集过程中，以何形式记录用户的回答。

如果是这个用户的信息，只一次性留存，可以使用词槽记录单元；

如果用户后期要长期带着这个标签属性，用属性写入单元记录；

如果用户的回复不仅需要自己随时能看到，还想让其他人看到，我们就使用表格写入单元。

另外有些营销类场景，实现过用户对哪方面感兴趣，虽然不提问但是需要记录下标签属性的需求；再者就是如在用户提前提供手机号的时候，也要将其记录。

1. 是否配置说明、上一步、退出等步骤

说明逻辑是指用户在有疑惑时如何与机器人交互才能拿到相应的解答和解释。

一般来说我们可以开启意图中允许在用户意图未能填槽时，允许用户提问并由机器人做回答，也可以单独配置跳转分支做出说明。

部分环节用户可能想要退回上一步进行选择，这个通过吾来的新功能也可以方便的配置。

沟通环节中，基本都需要考虑是否让用户可以直接退出任务，目前也可以在场景设置处进行个性化的退出配置。

1. 权限控制逻辑

通过读表、属性等单元相互组合，我们能高效实现白名单，分权限，分项目不同回答的配置。

使用吾来搭建任务对话部分往往非常迅速，但往往我们也需要花费时间在调试等工作上。

11.5任务调试常见问题

任务触发常见问题

有时候我们会发现任务没有按照设计的流程运行，那往往是在任务触发时出了问题： 1.任务没发布，没发布的任务就只是草稿状态，并未在线上运行； 2.任务没生效，用户消息不能触发意图并进入意图对应的流程； 3.任务没有触发词或者缺少跳转过来的设计； 4.错误的开启了“无意图”，若是相应对话触发“无意图”，那任务对话不会做回复； 5.错误的开启了“预处理意图”并且指向或结束于错误的分支。

那大家在触发任务的时候就可以按照这样几个步骤快速检查一下； 1.任务是否已发布； 2.任务是否已生效； 3.任务是否有对应的触发词或者相应的跳转逻辑； 4.是否可能触发了无意图； 5.是否可能开启了并错误的使用了预处理；

任务运行常见问题

如果遇到机器人运行过程中不符合预期，那我们可以查看调试信息或打开任务的调试模式看一下。

调试模式有两种开启方式，一个是在意图的配置选，另一个是在对应渠道输入“black sheep wall”（调试机器人，体验版机器人网页或其他正式渠道皆可，只要没被客服系统屏蔽都可以）。

也许有些人发现过自己的机器人在运行时会出现一些莫名其妙的文字，类似这张图的最后两段，这个大部分是由于开启了任务的调试中状态或者预处理，不想出现可以手动关闭。

如果发现任务机器人在调试过程中出现问题，往往可以从以下几个角度排查问题：

1. 观察调试中词槽的填槽状态： 可以说我们的任务对话搭建逻辑是依照填槽逻辑展开了，在未按照指定逻辑经过的时候，往往我们需要看看目前的填槽状态和值。

   • 检查是否已有值：在词槽中有值的时候，询问填槽不会主动询问；
   • 在抽取实体动作之后是不是有重置、清空或赋值：
   • 是否词槽在填槽之后被清空，尤其注意填槽之后接运算单元的，需要观察运算单元配置是否正确；
   • 观察词槽是否引用错误，在对引用了的词槽名称进行修改之后，需要观察引用处词槽名称是否与已更改的一致；
   • 填槽结果和预期不一致，可能是由于开启了整句填槽，或者配置了询问次数用尽后有填槽值；
   • 填槽次数、实体值、实体范围和刚刚设置的不一样，需要检查任务是否关联了正确的实体，是否实体能够成功被抽取出来，如已发布成功，如果检查了发布和生效可以稍等一会再来测试，词槽的生效时间在10分钟内；

2. 检查接口单元配置：在调试状态下如果发现走到接口单元失败往往有这么几个原因：

   • 接口单元返回格式不正确，返回超时；
   • 接口单元引用词槽时需要直接引用，不需要加“slot=”；
   • 接口单元在使用时，需要注意里面的变量是固定的默认值还是变量，要适时根据情况调整，更换接口链接时，也应注意；
   • 接口单元后面接的服务是否已经停用，比如服务器没开，依赖的服务到期欠费等等；
   • 接口单元对测试环境和正式环境的地址是或否有差异；

3. 任务出现循环，其表现是反复出现同样的回复或流经重复的流程。

4. 尽量在规划及搭建过程中，除用户的成功用例、失败用例，还要多考虑其他情况的分支，尤其是在将吾来作为语音场景对话管理平台时尤其要注意静默、重听、挂机、侮辱性话语、在忙等处理逻辑。在使用读写表单元、属性读写单元、接口单元时多注意失败（异常）分支的跳转关系配置。

任务意图的调试中状态方便我们观察是在哪一步的运行导致执行出现问题，通常在任务正式上线前有用；任务上线启用时，一般就不开这个选项了。

那么任务上线了之后，想要查问题时，在正式渠道更多的会使用触发任务后输入“black sheep wall”后再复现这种方法。

如果没有属性等受限于用户，渠道的特殊配置，我们通过任务调试信息功能就可以极速完成绝大多数的问题定位。

11.6 分类梳理原则与实践经验

机器人知识库必须有良好的分类才能便于理解、学习与后期的维护。

如若工作面对的是一个分类糟糕的知识库，这将是一个可怕的场景。拿到一个用户提问后，假设是人类来根据知识库里的知识点来回答问题。他会发现这么几件事，同一个问题可能会有多个知识点同时含有类似的问题，而且每个知识点的答案还都不太一样，在比较的时候易发现知识点都在不同的分类下面，整体的分类逻辑也令人摸不着头脑。

取消分类也是不可行的，知识库有20个知识点以上的时候，就必须要通过分类进行管理，才能有效梳理，否则，面对体量大的知识库，每一次整理都是漫漫征途。不能想象每次工作都要分辨1个知识点与其他成千上万个知识点的关系。

所以，当知识点逐渐变多后，我们需要一些合理的方式来对知识点的分类进行组织和管理。知识点组织的结构梳理有助于在知识库搭建过程中，给知识库里的知识点一个方便归纳的方法论。

1.分类原则和系统操作

知识库分类是按照知识点的特点和根据业务系统求解问题的需要将知识分为若干类，而每一类又分为若干子分类。一般子分类是母分类的基础，母分类是子分类的概括，子分类之间互不相容，知识库分类的划分遵循MECE的原则。

Tips

MECE分析法，全称 Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”。也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并成为有效解决问题的方法。

在知识库界面左侧是机器人知识点分类页面，点击分类名称旁边的“+”符号，可以新建此分类的下一级分类，鼠标悬停在对应分类上时还会有“编辑”、“删除”按钮浮出。当鼠标变成小手“ 👆 ”形状，可以拖动当前分类，改变其隶属关系，注意不能拖动为其本身的下一级。

点击向右的小三角“ ▶ ”可以展开下一级分类，点击向下的小三角“ ▼ ”可以收起属于该分类下的所有分类。

PS：为保证分类随知识库导出和导入正常，请不要在知识点分类中使用“/”、“\”等符号。

2.分类方法简述

2.1.分类纵向划分方法

在知识库构建过程中主要按照最终用户参与时间顺序构建分类的方法叫知识库的纵向划分方法。

纵向划分目前看来是我们搭建知识库的主要方法，在终端类公司，当已经分配了单一的业务线之后，在单一知识库中，往往是根据最终用户的参与时间进行划分。

消费产品类公司一般会按照售前，售后来区分知识库，售前还可能细分意图为优惠、产品信息、物流选择、支付办法等，售后分为物流状态、质量问题、包装问题等情况。当然，不同公司对物流等规划不完全一致，也有些公司是根据产品是否到达用户手中确定的售前售后，可以根据具体情况和实际进行微调。

服务类项目也可参照对应逻辑进行区分，比如餐饮项目按照就餐前和就餐后，人事服务类可以按照员工入职、试用期、转岗、离职的流程进行区分。

2.2.分类横向划分方法

知识库的横向划分结构主要用在产品业务线较多的情况下，并且往往是针对次一级分类进行划分，比如公司售卖的不同产品，可能就属于孕期-产品分类-不同产品进行划分。

通常在具体的分类过程中，也会结合具体业务情况将纵向划分与横向划分结合起来进行梳理。不同公司的业务模式不同，需要根据自己的实际情况进行知识库结构的确定。

2.3.分类经验概述

在实践中，我们总结了如下的分类口诀，帮助大家记忆：

一条主线，其他靠边；出现重复，早做功夫。

“一条主线”是说首先确认知识点是否以用户生命周期的场景展开，针对这类知识点，一般以最终用户参与的时间顺序作为唯一主线进行。

“其他靠边”指如果分类下知识点不是随着用户的生命周期变更的，如小区地点，小区周边这样的信息不会随着时间变化而变化，此时这类知识点可以单独拿出来作为项目的基础信息。

“出现重复，早做功夫”如果在不同阶段会出现重复，有没有明显应归类的位置，我们一般将知识点放在场景中最早提问的地方。

如果有并行的情况，比如信用卡办理的项目，线下办理为主线，同时有APP、微信、小程序、支付宝等渠道作为副线，需要明确副线的占比。 如果副线中APP开办差异占比较大，微信、小程序等渠道差异不大，有以下解决方案：

可以将APP渠道单独分类，在对应知识点下设计第二组答案，根据提问者带过来的标签，设计同一知识点根据属性实体等划分为不同答案组来进行个性化回复。

这个方案优点是可以直接根据用户提问的渠道做出最优的回答，但是需要APP渠道带属性接入或需要客户提供实体信息。 具体操作可以查看《什么样的回答才足够个性？吾来个性化回复举手参评》。

2.4.知识库分类实践

在实践中，根据知识库搭建是否有语料进行划分，我们有“从小到大”和“从大到小”的梳理方法。

何为从大到小呢？何为从小到大呢？其实二者的核心问题在于是否有语料，前者应该为无历史语料的场景下使用，后者则为有历史语料的情况下使用的。

1 从大到小

没有条件也要创造条件：业务框架

没有历史的语料情况下，我们普遍要依赖业务框架，那在没有业务框架情况下，首先要做的事情就是梳理业务框架，梳理好业务框架，往业务框架中不断地填充知识点及其相似问，用结构化的思想不断地界定知识库的边界，故为从大（业务框架）到小（知识点、相似问）：

第一步：用户群体分析

首先必不可少的是先确认机器人面对的用户群体有哪几类，分别是谁？先以外卖场景为例：

外卖行业智能客服的用户群体

第二步：用户行为分析

把用户行为作为落脚点去分析，如外卖行业的消费者，他的用户行为可以分为三大类：售前、售中、售后；那商家的用户行为可以分为3大类：未入驻商家、已入驻商家、商家账号注销；而骑手应该是：取餐、配送中、配送后；而后可以继续根据该逻辑扩充框架。

外卖行业智能客服的业务梳理大框架

可是当遇到业务场景之间无明显逻辑的时候应该怎么办呢？

第三步：产品功能分析

可以把现有产品的功能作为落脚点去分析，以支付宝的市民中心页面的办事大厅为例，可以将页面上的一个个业务当作框架的枝干：

支付宝-市民中心-办事大厅页面

根据以上产品功能梳理出来以下业务框架：

市民中心办事大厅业务框架

当我们梳理好业务框架，有了这么一棵树，接着就是要不断地往里面扩充知识点及其对应相似问，纳入对应的业务场景下；好比在树干（业务框架）上长出树枝（知识点），树枝上再不断地长出叶子（相似问）。

2 从小到大

充分利用尚方宝剑：历史语料

当有历史语料的情况下，我们可以通过一个个的用户query去提取核心内容，根据核心内容反推业务框架，故为从小（一个个用户query）到大（业务框架）。

如以下用户query：

1.你们的蜂蜜产品有什么优势？

2.蜂蜜枇杷露都有什么功效？

3.低血压可以吃哪款产品？

4.服用了蜂蜜枇杷露出现头晕症状？

5.蜂蜜枇杷露为什么会有白色沉淀物？

通过用户query提取核心内容：

1.你们的蜂蜜产品有什么优势？ ->售前问题-品牌优势

2.蜂蜜枇杷露都有什么功效？ ->售前问题-产品功效

3.低血压可以吃哪款产品？ ->售前问题-症状保健

4.服用了蜂蜜枇杷露出现头晕症状？ ->售后问题-服用症状

5.蜂蜜枇杷露为什么会有白色沉淀物？->售后问题-产品质量

当对一批用户问题进行了核心内容的提取，需要从整体角度上去看知识点的颗粒度，以及对应的业务场景、用户群体是否一致，如果不一致还需要调整；并且在知识库搭建完成上线后，需要密切关注用户交互数据，查看是否有漏网之鱼。

总的来说，搭建知识库需要从业务场景出发，优先解决高频问题；这样搭建的知识库，能够较好的应对风险并方便后续的维护优化。

Tips 颗粒度

我们将知识点包含范围的大小称作颗粒度。颗粒度大的知识点可以做适当拆分，主要利用知识点编辑卡片中的搜索相似问和添加为新知识点。相应地，知识点颗粒度过小，没什么人问，对用户没什么帮助并且意思相似又集中的，可以适当合并，应用的是相似问转移到已有知识点功能。

梳理知识库的几点原则

一切从业务场景出发，优先解决高频知识点，其次才是低频知识点与时效性较强的知识点；即使是在上线阶段也会不断添加新的知识点，因此在搭建初期应当首先考虑最高频、最痛点的知识点。

明确知识库边界，并不是所有的用户语句都适合作为知识点；另外，不同的产品知识库内可能会出现部分通用类型的问题，该类问题到底应该按照产品分类去整理还是统一纳入通用知识库里，应当结合业务场景来综合考虑，选择合适的方式。 在进行知识点整理的时候，最好制定统一的命名规范，方便后面管理。

知识库规模越大，管理难度就越大，因此当数据增量到一定程度的时候需要采取抽样检查或定期检查等方式来确保数据库的健康程度。例如查看有无失效知识点，有无漏网之鱼等等。

虽然分类不影响效果，但是在搭建过程中对机器人和运营人员有很大帮助。我们来想一下，如果用户的问题维护人员都不知道存在知识库的哪个部分，机器人能会吗？